The following are definitions of terms that will be used throughout the specification.
UNIX.TM.--An operating system that controls computer hardware. PA1 HLLAPI--High-level language application programmer interface--libraries of program commands provided by various vendors to operate a particular computer system. PA1 SSI.TM.--A high-level language application program. PA1 HCON.TM.--A high-level language application program provided IBM.TM.. PA1 AAPI.TM.--A high-level language application program provided by American Airlines.TM.. PA1 SABRE.TM.--American Airlines reservation computer system. PA1 SCRIPT --A group of program commands to a computer system. PA1 SHELL --Known computer program languages such as BOURNE, C, KORN, REXX, and the like. PA1 SCIP.TM.--The Shell communication interface program system of the present invention.
Historically, large corporations have centralized their data processing on large mainframe systems. Recently, these corporations have found it more cost effective to decentralize their departmental computing onto UNIX Systems. Unfortunately, UNIX and mainframe systems are not compatible. However, there are software packages which will allow UNIX users to communicate with the mainframes by emulating 3270 terminals. Several vendors offer 3270 emulation software packages including SSI and IBM. The SSI package is available for a variety of platforms and includes a complete implementation of the HLLAPI interface to 3270 emulation. The HCON package from IBM is available only for the IBM RS/6000 and offers the HLLAPI interface.
Providing the UNIX user with host-terminal emulation allows the user to access the host databases, upload and download data files and the like; however, this requires a considerable amount of operator intervention.
The present invention is a method and apparatus that provide the user with the ability to automate host tasks from any of the standard UNIX Shell languages and operate as a front end to the HLLAPI and Sabre interfaces available for the UNIX environment. The present invention is implemented as a UNIX utility providing host emulation capabilities along with the power and flexibility of the standard UNIX shell scripts. As a result, the user is allowed to-incorporate the functions of the present invention into the Shell language of their choice such as BOURNE, C Shell, KORN, REXX, and the like.
To incorporate the SCIP function of the present invention into a shell script, the user must first call SCIP to initiate a host conversation with the apparatus, open the host session, perform the host tasks and then close the session. When the conversation is initiated, a block of shared memory is allocated. This shared memory is used to maintain session information between subsequent calls to SCIP with the apparatus. Each time a new host session is opened, it is assigned a portion of the shared memory. If the command is not an "open" command, the shared memory is accessed to determine the last state of an existing program. This allows data for multiple sessions to be held in storage simultaneously and thus multiple sessions may be operated simultaneously through the use of multiplexing the command signals. The user may interactively switch between sessions by setting the SCIP apparatus to "setsession". All communications are then performed against the current session until another "setsession" process is established.
The SCIP translation command is used as a regular UNIX command in a shell script or is presented from a terminal. Since the SCIP translation command process exists only as long as it takes a single command to execute and terminate, it is necessary to maintain session connectivity information in a persistent area. This can be done in either a file or a shared memory. For the present invention, a shared memory is used. A shared memory under some UNIX Scripts requires a unique integer "key" for identification. When a process attaches or creates a shared memory segment, it uses the key as a global identifier. Thus without careful key management, it is possible that another programmer might accidentally use the same key which would probably destroy the contents of the shared memory segment and cause unpredictable behavior. This key can be generated from an entry in the filesystem which, when coordinated, prevents one program from accidentally using another program's key. The UNIX System V function is "ftok()", which returns the unique integer key based upon information associated with a file in the filesystem. This provides some insurance that the key will not be duplicated by another programmer as long as other programmers also use the same function. In addition to using the ftok() function to generate the key, the shared memory segment has user, group and world read-write permissions. If the SCIP program is configured to run "set-uid" under a SCIP login id, then only processes running as the user SCIP will be able to access the shared memory segment that it creates. This isolates any exposure from outside programmers from accidentally corrupting the shared memory segment. The present SCIP apparatus uses the shared memory segment to keep connectivity information and environment variable information necessary to communicate with the various 3270 emulation libraries such as HCON, SABRE or SSI. Upon its first invocation, the SCIP program tries to attach a shared memory segment using a predetermined filename (SCIP.sub.-- SHM) for a key, or, if the predetermined filename is not set, it generates its own. If the segment does not exist, it creates it.
Each time a segment is opened, connectivity information for that session is stored in a record in the shared memory segment. Each time a session is closed, after the driver-specific shutdown is performed, the record in shared memory is marked as "free". When all records in shared memory are marked "free", the shared memory segment (and its key) is deleted. The file used to generate the key can exist anywhere in the filesystem so long as it can be created as a real file by the SCIP translation program. The first time the SCIP translation program tries to attach to shared memory, if it does not find a shared memory segment, it creates one. When an open command is called, an unused record in the shared memory segment is selected and marked as the current session. Other sessions in progress can be used by using the "setsessions" which marks them as the current session. If no records are available, then the "open" command will fail.
A critical part of the design of the SCIP translation program is to allow the addition of new emulator support without impacting current support. In addition, it is desirable that the user be able to link in their own modules in order to expand the SCIP application program interfaces as needed. The present SCIP system uses a two-level dispatch table to route commands to the appropriate functions. The dispatch table consists of an array of structures which contain entries for global commands, each emulator type and user defined commands. Each of these entries contains a pointer to another array of structures containing the list of supported commands and the address of the function associated with the command.
Thus the system converts software commands generated in a first programming language environment to software commands that operate in one of a plurality of second programming language environments. A first computer system generates a program command signal in a first program language. A plurality of second vendor computer systems all have a second high-level language program different from each other and different from the first program language. The translation device is interposed between the first computer system and the plurality of second computer systems for storing a plurality of translation command rules for performing each high language level program designated by a program command signal. The SCIP translation device receives the input data signal in the first program language containing a vendor identification data portion and a program command data portion in the programming language of the first system and provides a corresponding output program command in the language of any selected one of the vendor computer systems.
The translation device consists of the first and second level dispatch tables plus a shared memory segment. The first level dispatch table is a channel selection station that identifies the types or class of computer systems having high-level languages such as SSI, HCON and AAPI that can be accessed by the system. The second level tables form a plurality of command channels, a corresponding one of which is designated for each of the high-level languages. Within each second level table is a list of the commands. Thus in the first level, an input command signal is received from the first computer system that includes a command portion that designates a function to be performed by one of the designated class of second vendor computer systems. The second level consists of a plurality of command dispatch units, or command channels, with each unit generating selected signals representing particular high-level language functions to be performed by a selected one of the second plurality of vendor computer systems according to the command data portion of the input data signal. The first level class table forwards the command portion of the data to the second level command table dispatch unit corresponding to the vendor identification portion of the input data signal.
An interface library memory is coupled to each of the command dispatch units for storing data in the first program language representing a plurality of high-level language command functions for each of the second vendor computer systems. A vendor library memory is coupled to the interface library and stores command functions/function rules in the second language to enable the selected one of the second plurality of vendor computer systems to perform the command. A shared memory segment is coupled to the interface library, the class dispatch table in the first level and the output of the vendor library for storing the data representing the vendor identification portion of the given input data signal to enable the appropriate interface library data to be selected that will designate the appropriate vendor library data and cause a command function to be performed by the selected one of the second vendor computer systems.
Thus it is the object of this invention to provide a method and apparatus to develop a script of commands on a first computer system that interfaces with a second computer system and that can be executed on, or by, a different first computer system to provide the same function without requiring any modifications.
It is also an object to the present invention to provide a method and apparatus for interfacing one program language with a selected one of a plurality of second program languages by using a first level table to receive an input data signal and select a designated one of a plurality of second level tables, each second level table containing commands for a designated one of the second program languages and a shared memory for storing data designating connectivity information for a selected second program language computer system.
It is still another object of the present invention to connect a host computer system utilizing a first program language to one of a plurality of vendor computer systems each using a unique second program language by initiating a host conversation, operating the host session, performing the host tasks and closing the session.